\section{\large Implication: what is the interface layer in software engineering?}
\label{sec:implication}

\textbf{Software engineering} and \textbf{machine learning} are two different disciplines in computer science.
Techniques in both disciplines evolved along parallel but separate tracks. Traditionally,
they have been viewed as separate domains and communities, with practitioners or researchers
specializing in one or the other. Furthermore, each has been considered ill-suited for the
tasks at which the other excels. This paper argues that the
difference is smaller than it appears and that certain of these
distinctions are unnecessary and counterproductive.

Because software plays a critical role in business, governments, and
societies, improving software productivity and quality is an important
goal of \textbf{software engineering} research.  In software development,
deployment, and maintenance, a huge wealth of various data exists in every
process, and hidden in the data is information about the quality of
software and services as well as the dynamics of software development.
Many software engineering
tasks, such as \textit{testing}, \textit{debugging}, \textit{bug predication}
, \textit{change analysis}, \textit{reverse engineering}, and
\textit{program refactoring}, need to deal with a huge wealth of various
data, such as \textit{code structure}, \textit{test execution}, \textit{program profile},
\textit{bug reports}, \textit{evolution history}, and \textit{program invariants}.
Typically, each software engineering task needs one of more kinds of data
as illustrated in Figure~\ref{fig:se}. Without an interface layer, an
$O$($n^2$) connections between tasks and available data is too costly
to use and evaluate, leaving only a few of the connections made in practice. In contrast,
an ideal way to push the frontier of software engineering research is
to propose, evaluate, and compare different techniques for each task
on a fair basis via an interface layer, as indicated in Figure~\ref{fig:sei}.





\begin{figure*}[t]
\begin{minipage}[b]{0.5\linewidth}
\centering
\includegraphics[scale=0.32]{graph1}
\caption{Typical software enginnering tasks (in the lightblue box)
and the data (in the lightgreen box) they may use. Lacking an interface
layer can lead to $O$($n^2$) connections between tasks between
data, given $n$ different tasks and $n$ different kinds of data.}
\label{fig:se}
\end{minipage}
\hspace{0.5cm}
\begin{minipage}[b]{0.5\linewidth}
\centering
\includegraphics[scale=0.32]{graph2}
\caption{An interface layer provides the benefits of reducing
$O$($n^2$) connections between software engineering tasks and
the data they may use to $O$($n$). The software engineering
tasks and the data are the same as in Figure~\ref{fig:se}
shows.}
\label{fig:sei}
\end{minipage}
\end{figure*}


\begin{figure*}[t]
\begin{minipage}[b]{0.5\linewidth}
\centering
\includegraphics[scale=0.32]{graph3}
\caption{The state-of-the-art testing-based automated fault
localization techniques (in the lightblue box) and the
data (in the lightgreen box) they may use. The same $O$($n^2$)
connections are observed as Figure~\ref{fig:se}.}
\label{fig:fault}
\end{minipage}
\hspace{0.5cm}
\begin{minipage}[b]{0.5\linewidth}
\centering
\includegraphics[scale=0.32]{graph4}
\caption{The unified framework based on Markov logic network
presented in this paper serves as an interface layer for
testing-based fault localization techniques, resulting in
a $O$($n$) connection as Figure~\ref{fig:sei} indicates.}
\label{fig:faulti}
\end{minipage}
\end{figure*}


As an evidence of the $O$($n^2$) problem, Figure~\ref{fig:fault}
shows the relations between a number of the state-of-the-art automated
testing-based fault localization techniques and the data that they
may use. We can find only a few connections between techniques
and available data have been explored in the literature and evaluated,
leaving a fairly large amount of unknown spaces for future exploration. This
reflects the high cost of the $O$($n^2$) problem in practice, and the need
of an interface layer with which each innovation can be connected with
the available data, as indicated by Figure~\ref{fig:faulti}.

\textbf{Machine learning} is a scientific discipline concerned with the design
 and development of algorithms that allow computers to evolve behaviors based
on empirical data. A machine learner can take advantage of examples (data) to
capture characteristics of interest of their unknown underlying probability distribution.
Data can be seen as examples that illustrate relations between observed variables.
One of the major focuses of machine learning research is to automatically learn
to recognize complex patterns and make intelligent decisions based on data.

The adaption of machine learning techniques in software engineering research
has the potential of push the frontiers of both disciplines.
With existing machine learning technologies (e.g., inductive learning, graphical models
, and feature learning), software engineering community 
is to enable software practitioners to perform data exploration and gain
insightful information that conveys meaningful
and useful understanding or knowledge towards performing the target task. Typically, insightful information is not easily attainable by
directly investigating the raw data without aid of learning technologies.
Actionable information is information upon which software practitioners can come up with concrete solutions
towards completing the target task.

On the other hand, software engineering research may foster the
development of new learning technologies, such as ways to
develop problem formulation, algorithms, and systems to explore, understand,
and get insights from the specific software engineering data.



This section notes that software engineering and machine learning
research can interact: by augmenting one another, by inspiring new
algorithms, and by creating interface layers that combine them. Some
of these seem to have been overlooked in the literature.
Finally, a more broader open question derived from this report is: what can be a
suitable interface layer for software engineering?  What is the right
abstraction for representing software engineering tasks in an abstract
domain? Those questions are worth exploring in the future.

